文章同步於Blog
今天我們會來介紹什麼是Coding Style,以及團隊的Coding Style為什麼應該統一
在 Python 使用 import this
會跳出以下資訊
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
我們可以很清楚的知道 Python 強調可讀性、清楚的 Code 為原則
這和我們之後的Clean Code的理念是相似的
其實就是指每個工程師Coding的風格,舉個例子
以命名來說常見的就有
還有縮排、常數、註解等等
然後註解這一部分我等等會花時間特別解釋
我們一開始在學習寫程式時,通常都是一個人在寫
這種時候就算你把變數命名為 a
也沒什麼差別,反正自己知道就好
但當我們開始和其他人一起協作的時候,這時候我想團隊內的成員應該會當場中風
團隊協作時,不統一的Coding Style團隊協作時,不統一的 Coding Style 會造成維護上的負擔
A同事用小駝峰,B同事用蛇型
一開始還好,但專案開始大起來、或是你哪天接手的時候,你可定要花上一段時間去Study前人到底在幹嘛
為了避免這種狀況,團隊中的Coding Style統一就非常重要
隨著專案擴大,當程式碼越做越多時,開發時間會越來長
但雜亂無章的程式碼到最後只會讓開發效率無限趨近於0,此時公司就只能請更多人來維護跟撰寫
此時新人如果不知道會不會有改了A就影響到B的狀況,又加上有時程壓力的話就容易導致持續產出髒扣
最終就變成一個無限迴圈
$is_code_dirty = true;
while ($is_code_dirty) {
echo 'PM: 我們需要某某功能喔';
echo '程式碼太糟糕了怎麼辦,東西改不完啦!!!';
echo '有了應徵新的人吧!!!';
echo '!@#!@,這些事什麼鬼???';
echo '不行了,Deadline要到了,不管了隨便寫啦';
echo '呼,完成了~';
$is_code_dirty = true;
}
這個做法就完全是在帶來麻煩(aka創造職缺)
關於註解這一部分我想特別挑出來說的原因就是,其實程式碼邏輯且命名清楚
這種情況下就不太需要寫註解
這派的人主張,通常寫註解的原因是因為Code寫太爛才需要
舉個例子
def sum_two_argument(a, b):
"""相加兩個字串"""
return a + b
這種情況下就可以從根本做起,把Typing Hint打好,然後就可以不需要寫註解
真的忘記我滑鼠滑上去function上也可以知道要帶什麼參數進去
真的要寫註解的情況之後有說到Clean code這本書時再來做說明
Coding Style
Clean Code(ch.1)